An IP Multimedia Subsystem (IMS) policy control mechanism (i.e. a Service Based Local Policy (SBLP)) and a Flow Based Charging (FBC) technology are specified in Third Generation Partnership Project (3GPP) R6 protocol standards. However, the policy control involves numerous functions similar to those of the Flow Based Charging with respect to particular procedures, and the separation of the policy control and the Flow Based Charging necessarily results in the increased complexity of network configuration and the increased cost, furthermore, the control efficiency is reduced, thus influencing user experience. The standard of the 3GPP Release 7 converges the policy control and the Flow Based Charging and proposes a Policy Control and Charging (PCC) architecture, as illustrated in the broken line block of FIG. 1, the architecture includes an Online Charging System (OCS) which further includes a Customized Applications for Mobile Network Enhanced Logic Service Control Point (CAMEL SCP) and a Service Data Flow Based Credit Control.
An Application Function (AF) is an application function entity such as a Proxy Call Session Control Function (P-CSCF) in the IMS, and is adapted to provide a Policy Control and Charging Rules Function (PCRF) with dynamic session information for policy establishment and charging control. The PCRF is adapted to, in accordance with application layer service information, bearer layer information, local operator configuration and a user subscription profile, provide a Policy and Charging Enforcement Function (PCEF) with QoS authorization and charging rules and make a decision of a gating function on user plane data (for example, disabling of gating, and discarding of an IP packet). The PCEF is typically arranged in a Gateway (GW) such as a Gateway GRPS Support Node (GGSN) in the General Packet Radio Service (GPRS), and is adapted to, in accordance with the policy rules sent from the PCRF, perform QoS processing, detect a service data flow and perform such a function as online/offline charging. A Subscription Profile Repository (SPR) is a logical entity adapted to store and provide the user subscription profile required for policy establishment and charging control for the PCRF.
With the PCC architecture, an operator may perform a control on QoS, charging, etc., of a data flow at the bearer layer, thereby enabling details of a transport network to be hidden from the upper service layer, in other words, the service layer is above a bearer control layer, and the bearer control layer hides the details of the bearer layer from the service layer; and perceiving the usage of resources at the lower transport network. The PCRF, on one hand, may establish a policy in accordance with session negotiation information indicated by the service layer to control the usage of network resources at the bearer layer, and on the other hand, notify the service layer through a reporting mechanism of a change on the usage of the underlying bearer, such as a resource loss and a gateway failure, so that the service layer may make an appropriate modification and provide a corresponding policy.
The following two terms are explained firstly for the sake of descriptions.
Flow identifier information: The flow identifier information is expressed as a 2-tuple <a media component number (for example, a Media Component Number AVP), an IP flow number (for example, a Flow Number VAP)>. The media component number identifies a media type, such as an audio flow and a video flow. A media component may include one or more IP flows. The flow identifier information is derived from the Session Description Protocol (SDP) information obtained after session negotiation and uniquely identifies a media IP flow.
2. A 5-tuple (for example, a Flow Description AVP): The 5-tuple consists of <a source address, a source port number, a destination address, a destination port number, a protocol>. The source address and the source port number identify an IP address and a port number of an initiator of a session, the destination address and the destination port number identify an IP address and a port number of a receiver of the session, and the protocol identifies a protocol used for transport of a media IP flow. The 5-tuple identifies uniquely a media IP flow and is adapted for associating the media IP flow with a specific bearer during the session (which is implemented by binding the 5-tuple with a Traffic Flow Template (TFT) identifying uniquely the bearer). The 5-tuple is derived in accordance with the SDP for session negotiation.
In the specification of the PCC architecture, the AF subscribes to the usage of a media bearer, thus allowing a media bearer event to be reported. Upon detection of a bearer event, the PCEF reports the bearer event to the PCRF and requests a new policy. The PCRF notifies the AF of the change of the bearer corresponding to an IP flow through event reporting before establishing the new policy. The AF sends to the PCRF the adjusted session information, based on which the PCRF establishes new PCC rules. A specific implementation of subscribing to a media bearer event and reporting the media bearer event is illustrated in FIG. 2.
Steps S201-S206 illustrate a procedure of subscribing to a bearer event report and are described as follows.
Step S201. The AF sends application layer service information to the PCRF, to subscribe to a bearer event report. Session parameters such as a parameter of media component number (i.e. a Media Component Number AVP), a parameter of flow number (i.e. a Flow Number AVP), a parameter of 5-tuple (i.e. a Flow Description AVP) and a parameter of specific action (i.e. A Specific Action AVP) indicating a specific bearer event (such as a bearer loss and a bearer release) to be subscribed to, are carried in an Authorize-Authenticate-Request (AAR).
Steps S202-S203. The PCRF stores the received session parameters and returns an Authorize-Authenticate-Answer (AAA) response.
Step S204. The PCRF establishes and stores PCC rules in accordance with service layer information, bearer layer information (provided to the PCRF by the PCEF upon a PDP context establishment request), a subscription profile and a local policy of an operator.
Steps S205-206. The PCRF sends PCC rules to the PCEF through a parameter of Charging Rule Install in a Re-Auth-Request (RAR) message, with the PPC rules being carried in the parameter of Charging Rule Install. Further, the RAR message includes PCC rule names generated for the PCC rules.
If not requested previously the PCEF to detect a bearer event, the PCRF carries a parameter of Event Trigger for indicating a specific bearer event to be detected, such as a bearer loss and a bearer release.
Steps S207-S211 illustrate a procedure of reporting a bearer event and are described as follows.
Step S207. A bearer event is detected by the PCEF.
Steps S208-S209. The PCEF reports the PCC rule names associated with the bearer to the PCRF, through a parameter of Charging Rule Report carrying the PCC rule names in a Credit-Control-Request (CCR) message. During the reporting, the parameter of Event Trigger indicating the bearer event is also carried. Upon receiving the message, the PCRF returns a Credit-Control-Answer (CCA) message to the PCEF.
Steps S210-S211. The PCRF reports to the AF an identifier of the influenced media IP flow along with the bearer event in accordance with the PCC rule names reported by the PCEF. The RAR message carries a parameter of Flows which indicates identifier of the media IP flow associated with the bearer event, and the parameter of Flows includes a media component number and a flow number. The RAR message further carries a parameter of specific action indicating the specific bearer event. Upon receiving the message, the AF returns an RAA message to the PCRF.
With the mechanism of reporting a bearer event, the bearer layer may notify timely the service layer of the bearer event to request a new policy, when a bearer change such as a bearer resource loss and a gateway failure occurs. The service layer perceives the bearer change with the reporting mechanism, and responds to the bearer change, for example, the service layer may request a session modification, a session termination and the like.
Similar to a media IP flow, a signaling IP flow during a session also utilizes a bearer, and the service layer needs to know timely conditions of the underlying bearer related to the signaling. When the bearer related to the signaling is changed, the bearer needs to report a bearer event to the service layer, so that the service layer may make a corresponding modification timely. An existing method for reporting a status of a signaling path is as follows.
A signaling tag is carried in a Packet Data Protocol (PDP) activation request by a User Equipment (UE). The PCRF perceives that a PDP context to be established is used to bear IP signaling, and establishes and sends PCC rules to the PCEF, thereby establishing the PDP context with the signaling tag. Upon subscribing to a signaling path status report, the AF carries a signaling IP flow tag to notify the PCRF about the subscription to a signaling event. Upon detection of a change on the bearer with the signaling tag, the PCEF reports to the PCRF the PCC rule names associated with the bearer, and the PCRF perceives a change of the PDP context bearing the signaling in accordance with the PCC rule names, so that the signaling path status is reported to the AS.
A specific implementation of reporting a signaling path status is illustrated in FIG. 3.
The steps S301-S307 illustrate a procedure of establishing a PDP context with a signaling tag and are described particularly as follows.
Step S301. The PCEF receives from a UE a PDP context activation request carrying a signaling tag.
Step S302. The PCEF sends a PDP context establishment request to the PCRF. The CCR message carries bearer layer information such as a parameter of Bearer Usage, which indicates that establishment of a PDP context with the signaling tag is requested. Optionally, the PCRF returns a CCA message to the PCEF (not shown).
Step S303. The PCRF stores the received bearer layer information, and perceives that the PDP context to be established as requested is used to bear IMS signaling in accordance with the parameter of Bearer Usage.
Step S304. The PCRF generates PCC rules and the corresponding PCC rule names in accordance with the bearer layer information, a subscription profile and an operator policy.
Steps S305-S307. The PCRF sends the PCC rules and the corresponding PCC rule names to the PCEF, and the PCEF installs the PCC rules and returns a response to the PDP context activation request to the UE, so that the PDP context with the signaling tag is established.
The steps S308-S312 illustrate a procedure of subscribing to a signaling path status report and are described particularly as follows.
S308-S310. When a session message arrives at an AF, the AF initiates a subscription to a signaling path status report. Parameters of Flow Usage (set as AF signaling, which indicates a subscription related to a signaling event) and specific action (indicating a specific subscribed event, such as a bearer loss and a bearer release) are carried in An AAR message. The PCRF perceives that this subscription is a subscription related to a signaling patch status in accordance with the value of the parameter of Flow usage.
S311-S312. The PCRF sends the PCC rules to the PCEF. A parameter of Charging Rule Install indicating the PCC rules is carried in an RAR message. If detection of the bearer event by the PCEF is not subscribed to, the PCRF initiates subscription, with a parameter of Event Trigger indicating a specific bearer event being carried. The parameter of Event Trigger is generated in accordance with the parameter of specific action.
The steps S313-S318 illustrate a procedure of reporting a signaling path status and are described particularly as follows.
Step S313. A bearer event is detected by the PCEF.
Steps S314-S315. The PCEF reports the PCC rules associated with the bearer to the PCRF.
Steps S316-S318. The PCRF determines a change of a PDP channel bearing IMS signaling in accordance with the PCC rule names and reports the signaling patch status.
The implementation of the existing mechanism for reporting a signaling path status is dependent on the parameter of Flow Usage. Upon initiating a subscription to a signaling path status, the service layer uses the parameter of Flow Usage as an AF signaling identifier to notify the PCRF of the signaling-related subscription. As defined currently, however, the parameter of Flow Usage exists as a sub-parameter of a parameter of Media Sub-Component, and the parameter of Flow Usage has to be used along with the parameters of Media Component Description and Media Sub-Component. For a signaling IP flow, no value of the parameter of Media Component Description or the parameter of Media Sub-Component is defined in the existing standard, as a result, no signaling information is allowed to be reported and consequently no mechanism for reporting a signaling path status can be implemented.